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REMARKS/ARGUMENTS 

The Office Action mailed February 6, 2008, has been received and reviewed. Claims 1-15 
are currently pending in the application. Claims 1-15 stand rejected. Applicant has amended 
claim 5, and respectfully requests reconsideration of the application as amended herein. 

35 U.S.C. § 101 Rejection 

Claims 5 and 6 stand rejected under 35 U.S.C. § 101, asserting that the claimed invention 
is directed to non- statutory subject matter. Applicant has amended independent claim 5 to recite, 
in part, "A method for forming a communication signal for transmitting via a carrier wave, 
comprising: . . . ." Therefore, Applicant is no longer claiming a "signal" per se. Accordingly, 
amended independent claim 5 reciting a "method for forming a communication signal" falls 
within one of the statutory classes, namely a "process". 

Regarding dependent claim 6, claim 6 recites a "method" which now finds antecedent 
basis in amended independent claim 5 from which claim 6 depends. Accordingly, Applicant 
respectfully requests the rejections be withdrawn. 

35 U.S.C. § 112 Claim Rejection 

Claim 6 stands rejected under 35 U.S.C. § 1 12, second paragraph, as being indefinite for 
failing to particularly point out and distinctly claim the subject matter which applicant regards as 
the invention. Applicant respectfully traverses this rejection, as hereinafter set forth. 

The Office Action cites the "method" preamble limitation of dependent claim 6 while no 
antecedent basis exists for the method. Applicant has amended independent claim 5 from which 
claim 6 depends to recite, in part, "A method for forming a communication signal for 
transmitting via a carrier wave, comprising: . . . ." Therefore, the "method" preamble of 
dependent claim 6 now finds antecedent basis in amended independent claim 5. Therefore, 
Applicant respectfully requests the rejection be withdrawn. 
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Claim Rejections Under 35 U.S.C. § 103 

Claims 1-15 were rejected as being unpatentable over U.S. Patent 6,542,490 to 
Ahmadvand et al ("Ahmadvand") in view of U.S. Patent 6,032,197 to Birdwell et al 
("Birdwell"). Applicant respectfully traverses this rejection, as hereinafter set forth. 

To establish a prima facie case of obviousness the prior art reference (or references when 
combined) must teach or suggest all the claim limitations. In re Royka, 490 F.2d 981, 985 
(CCPA 1974); see also MPEP § 2143.03. Additionally, there must be "a reason that would have 
prompted a person of ordinary skill in the relevant field to combine the [prior art] elements" in 
the manner claimed. KSR Int'l Co. v. Teleflex Inc., Ill S. Ct. 1727, 1742, 167 L.Ed.2d 705, 75 
USLW 4289, 82 U.S.P.Q.2d 1385 (2007). Finally, to establish a prima facie case of obviousness 
there must be a reasonable expectation of success. In re Merck & Co., Inc., 800 F.2d 1091, 1097 
(Fed. Cir. 1986). Furthermore, the reason that would have prompted the combination and the 
reasonable expectation of success must be found in the prior art, common knowledge, or the 
nature of the problem itself, and not based on the Applicant's disclosure. DyStar Textilfarben 
GmbH& Co. Deutschland KG v. C. H. Patrick Co., 464 F.3d 1356, 1367 (Fed. Cir. 2006); 
MPEP § 2144. Underlying the obvious determination is the fact that statutorily prohibited 
hindsight cannot be used. KSR, 111 S.Ct. at 1742; DyStar, 464 F.3d at 1367. 

The 35 U.S.C. § 103(a) obviousness rejections of claims 1-15 are improper because the 
elements for a prima facie case of obviousness are not met. Specifically, the rejection fails to 
meet the criterion that the prior art references must teach or suggest all the claims limitations. 

The Examiner, in the Response to Arguments section, acknowledges that Birdwell's "16- 
bit protocol block 42 identifies the protocol format for the header 40". (Office Action, p. 7; 
emphasis added). The Examiner then alleges that the "16-bit protocol block can have different 
formats as suggests by Birdwell such as TCP/IP, IPX/SPX. and NetBEUI". (Office Action, p. 
7; emphasis added). Note-Birdwell specifically teaches "A 16-bit protocol block 42 identifies 
the protocol format for the header 40 |"|In this case, the protocol block 42 contains the protocol 
number "0x0800". which specifies the UDP/IP protocol." (Birdwell. col. 4, lines 55-58). 
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The Examiner then alleges 'using these different format headers 42 the payload of the 
packet will be constructed according to the protocol format of the header." (Office Action, p. 7; 
emphasis added). Applicant agrees that Birdwell teaches, for example, "the protocol block 42 
contains the protocol number "0x0800", which specifies the UDP/IP protocol." (Birdwell, col. 
4, lines 57-58; emphasis added). However, Applicant respectfully asserts that "specifying] ... 
fa] protocoF does not teach Applicant's claimed element of "identifying a payload type". 
Specifically, Birdwell's actual "protocol" and "payload" teachings include "specifying] ... [a] 
protocol" which includes identifying header fields and field lengths (see Birdwell, col. 4, line 54- 
col. 5, line 41) and associating an X-bit data payload to the header (see Birdwell, col. 5, lines 53- 
58). No where does Birdwell teach that "specifying] ... [a] protocol" also further teaches 
"identifying apayload type" as claimed by Applicant. Even assuming for the sake of argument 
that Birdwell's teaching of "specifying] ... [a] protocol" extends to teaching the "size" of the X- 
bit data payload, Birdwell's teaching of "specifTyingl ... [a] protocol" clearly does not teach 
"identifying a payload type" as claimed by Applicant. Specifically, the identification of a 
protocol format does not also teach "identifying a payload type" as claimed by Applicant. 

Accordingly, these references cannot render obvious, under 35 U.S.C. §103, Applicant's 
invention as presently claimed because Ahmadvand in view of Birdwell does not teach all of the 
claims limitations. Applicant submits that Ahmadvand in view of Birdwell does not render 
obvious, under 35 U.S.C. § 103, the presently claimed invention of (i) independent claim 1 and 
claims 2-4 and 1 1 depending therefrom, (ii) independent claim 5 and claim 6 depending 
therefrom, (iii) independent claim 7 and claims 8-10 depending therefrom, and (iv) independent 
claims 12-15, because Ahmadvand in view of Birdwell does not teach or suggest all of the 
claims limitations. Accordingly, Applicant respectfully further sustains the below arguments. 

Claims 1, 12 and 14 

Applicant respectfully disagrees that Ahmadvand in view of Birdwell renders obvious 
Applicant's invention as claimed in independent claims 1, 12 and 14 which read: 
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1. A method for framing packets in a wireless transmission system supporting 
broadcast transmissions, the method comprising: 

generating a portion of an Internet Protocol (IP) packet for transmission; 

appending a start of frame indicator to the portion of the IP packet; 

applying an error checking mechanism to the portion of the IP packet not 

including a protocol field to identify a payload type, 
preparing a frame for transmission, having the start of frame indicator, the portion 

of the IP packet, and the error checking mechanism; and 
transmitting the frame without the protocol field. (Emphasis added). 

12. An apparatus for framing packets in a wireless transmission system 
supporting broadcast transmissions, the apparatus comprising: 

means for generating a portion of an Internet Protocol (IP) packet for 
transmission; 

means for appending a start of frame indicator to the portion of the IP packet; 

means for applying an error checking mechanism to the portion of the IP packet; 

means for preparing a frame for transmission, having the start of frame indicator, 
the portion of the IP packet and the error checking mechanism and not 
including a protocol field to identify a payload type; and 

means for transmitting the frame without the protocol field. (Emphasis added). 

14. A computer program stored on a computer-readable storage unit, the 
computer program for framing packets in a wireless transmission system supporting 
broadcast transmissions, the computer program comprising: 

a first set of instructions for generating a portion of an Internet Protocol (IP) 
packet for transmission a second set of instructions for appending a start 
of frame indicator to the portion of the IP packet; 
a third set of instructions for applying an error checking mechanism to the portion 
of the IP packet; 

a fourth set of instructions for preparing a frame for transmission, having the start 
of frame indicator, the portion of the IP packet and the error checking 
mechanism and not including a protocol field to identify a payload type; 
and 

a fifth set of instructions for transmitting the frame without the protocol field. 
(Emphasis added). 

Applicant respectfully asserts that Applicant's invention as presently claimed in 
independent claims 1, 12 and 14 recite, in part, ' not including a protocol field to identify a 
payload type " and 'the frame without the protocol field". The Office Action alleges: 
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Regarding claims 1, 12, and 14, ... Ahmadvand fails to teach for framing and 

transmitting IP packet not including a protocol field. 
However, Birdwell discloses a broadcast transmission system for transmitting IP packets 

using compress[ed] header, wherein the protocol field of the packet is not used in 

the compressed header (fig. 5 col. 5 lines 59-65). (Office Action, pp. 3-4; 

emphasis added). 

Applicant respectfully asserts that Applicant's entire claim language has not been applied 
in the rejection. Generally, the alleged un-included "protocol" field in Birdwell is for identifying 
a "header" format and not a "payload type" as claimed by Applicant. Specifically, Applicant's 
invention as presently claimed in independent claims 1,12 and 14 recite, in part, "protocol field 
to identify a payload type ". However, the "protocol" field of Birdwell is completely unrelated to 
the payload type and applies to a "header" type. Specifically, Birdwell teaches with reference to 
Birdwell's Figs. 4-5: 

A 16-bit protocol block 42 identifies the protocol format for the header 40. (Birdwell, 
col. 4, lines 55-56; emphasis added). 

Clearly, the "protocol field" 42 that is present in packet 50 of Birdwell's Fig. 4 and 

absent in packet 60 of Birdwell's Fig. 5 is not "a protocol field to identify a payload type" as 

claimed by Applicant. Furthermore, Birdwell is clear that the field that identifies the "payload 

type" is present in both packet 50 of Birdwell's Fig. 4 and packet 60 of Birdwell's Fig. 5. In this 

regard, Birdwell specifically teaches: 

The 16-bit packet identification field, for example, is the same in both uncompressed 
headers [40 of Birdwell's Fig. 4] and compressed headers [62 of Birdwell's Fig. 
5]. (Birdwell, col. 5, lines 34-36; emphasis added). 

Therefore, since by the Office Action's admission, "Ahmadvand fails to teach ... IP 
packet not including a protocol field" (Office Action, p. 3) and Birdwell's teaching that the 
"packet identification field [] is the same in both uncompressed headers and compressed 
headers" (Birdwell, col. 5, lines 34-36), these references, either individually or in any proper 
combination, do not teach or suggest Applicant's invention as presently claimed in independent 



Attorney Docket No. : 0 1 0498 
Customer No.: 23696 



10 



Serial No. 09/933,639 

claims 1,12 and 14 reciting, in part, 'not including a protocol field to identify a payload type" 
and "the frame without the protocol field". 

Accordingly, these references cannot render obvious, under 35 U.S.C. §103, Applicant's 
invention as presently claimed in independent claim 1 and claims 2-4 and 1 1 depending 
therefrom, and independent claims 12 and 14, because Ahmadvand in view of Birdwell does not 
teach or suggest all of the claims limitations. 

Claim 5 

Applicant respectfully disagrees that Ahmadvand in view of Birdwell renders obvious 

Applicant's invention as claimed in independent claim 5 which reads: 

5. A method for forming a communication signal for transmitting via a carrier 
wave, comprising: 

generating a payload portion corresponding to a portion of an Internet Protocol 

(IP) packet of digital information and not including a protocol field to 

identify a payload type; 
generating a start of frame portion corresponding to the payload portion, and 

identifying a status of the payload portion within an IP packet; and 
generating an error checking portion for verifying the payload portion. (Emphasis 

added). 

Applicant herein sustains the above-proffered arguments. Therefore, since by the Office 
Action's admission, "Ahmadvand fails to teach ... IP packet not including a protocol field" 
(Office Action, p. 3) and Birdwell's teaching that the "packet identification field [] is the same in 
both uncompressed headers and compressed headers" (Birdwell, col. 5, lines 34-36), these 
references, either individually or in any proper combination, do not teach or suggest Applicant's 
invention as presently claimed in independent claim 5 reciting, in part, "not including a protocol 
field to identify a payload type". 

Accordingly, these references cannot render obvious, under 35 U.S.C. §103, Applicant's 
invention as presently claimed in independent claim 5 and claim 6 depending therefrom, because 
Ahmadvand in view of Birdwell does not teach or suggest all of the claims limitations. 
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Claims 7, 13 and 15 

Applicant respectfully disagrees that Ahmadvand in view of Birdwell renders obvious 

Applicant's invention as claimed in independent claims 7, 13 and 15 which read: 

7. A method for receiving framed packets in a wireless transmission system 
supporting broadcast transmissions, the method comprising: 

receiving a frame of a packet transmission wherein the frame contains a payload 
portion of an Internet Protocol (IP) packet and does not include a protocol 
field to identify a payload type, the frame having a start of frame portion, 
a payload portion, and an error check portion, the frame not including the 
protocol field; 

identifying the frame as a start frame in the packet transmission; 
verifying the frame using the error check portion of the frame; and 
processing the payload portion of the frame. (Emphasis added). 

13. An apparatus for receiving framed packets in a wireless transmission system 
supporting broadcast transmissions, the apparatus comprising: 

means for receiving a frame of a packet transmission wherein the frame contains a 
payload portion of an Internet Protocol (IP) packet and does not include a 
protocol field to identify a payload type, the frame having a start of frame 
portion, a payload portion, and an error check portion, the frame not 
including the protocol field; 

means for identifying the frame as a start frame in the packet transmission; 

means for verifying the frame using the error check portion of the frame; and 

means for processing the payload portion of the frame. (Emphasis added). 

15. An computer program stored on a computer-readable storage unit, the 
computer program for receiving framed packets in a wireless transmission system 
supporting broadcast transmissions, the computer program comprising: 

a first set of instructions for receiving a frame of a packet transmission wherein 
the frame contains a payload portion of an Internet Protocol (IP) packet 
and does not include a protocol field to identify a payload type; the frame 
having a start of frame portion, a payload portion, and an error check 
portion, the frame not including the protocol field; 

a second set of instructions for identifying the frame as a start frame in the packet 
transmission; 

a third set of instructions for verifying the frame using the error check portion of 
the frame; and 

a fourth set of instructions for processing the payload portion of the frame. 
(Emphasis added). 
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Applicant herein sustains the above-proffered arguments. Therefore, since by the Office 
Action's admission, "Ahmadvand fails to teach ... IP packet not including a protocol field" 
(Office Action, p. 4) and Birdwell's teaching that the "packet identification field [] is the same in 
both uncompressed headers and compressed headers" (Birdwell, col. 5, lines 34-36), these 
references, either individually or in any proper combination, do not teach or suggest Applicant's 
invention as presently claimed in independent claims 7, 13 and 15 reciting, in part, "does not 
include a protocol field to identify a payload type". 

Accordingly, these references cannot render obvious, under 35 U.S.C. §103, Applicant's 
invention as presently claimed in independent claim 7 and claims 8-10 depending therefrom, and 
independent claims 13 and 15 because Ahmadvand in view of Birdwell does not teach or suggest 
all of the claims limitations. 
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CONCLUSION 

Claims 1-15 are believed to be in condition for allowance, and an early notice thereof is 
respectfully solicited. Should the Examiner determine that additional issues remain which might 
be resolved by a telephone conference, he is respectfully invited to contact Applicant's 
undersigned attorney. 

Please charge any fees or overpayments that may be due with this response to Deposit 
Account No. 17-0026. 



Date: May 6, 2008 Signature: /Roberta A. Young, No. 53,81 8/ 



Roberta A. Young, Reg. No. 53,818 
QUALCOMM Incorporated (858) 658-5803 

Attn: Patent Department 
5775 Morehouse Drive 
San Diego, California 92121-1714 
Telephone: (858) 658-5787 
Facsimile: (858) 658-2502 
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